REMARKS 

In the Office Action mailed November 16, 2007 claims 1-14 and 16-19 are currently 
pending. Claims 1-14 and 16-19 stand rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Jordan et al. (US Patent No. 6,438,652) in view of Zisapel et al. (US Patent 
No. 6,665,702) in view of "Applicants Admitted Prior Art (AAPA)" and in view of Primak et al. 
(US Publication No. 2001/0039585). 

Applicants respectively traverse. After a careful review of the Office Action, Applicants' 
claim clarifications, and the cited references, Applicants respectively request reconsideration in 
view of the following remarks. 

I. CLAIM REJECTIONS UNDER 35 U.S.C. $ 103(a) 

Claims 1-14 and 16-19 are rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Jordan et al. (US Patent No. 6,438,652) in view of Zisapel et al. (US Patent 
No. 6,665,702) in view of Applicants Admitted Prior Art (AAPA) and in view of Primak et al. 
(US Publication No. 2001/0039585). Applicants respectively traverse. 

A. Applicant's Presently Claimed Invention 

This present invention relates to load balancing. More specifically, it relates to using a 
proxy server to provide load balancing. (Applicant's Specification at p. 2, lines 4-7). 

As Applicants previously explained, the system and method of the present invention 
advantageously provides a system for load balancing. Specifically, a control node may be 
provided that balances the traffic load sent to proxies in a network. The control node may 
maintain information that assigns the traffic load to the proxies. 

In one example of the present invention, a control node is coupled to a plurality of 
proxies. The control node may receive information from the plurality of proxies, maintain a list 
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of all proxies, and assigns a weight to each of the proxies in the list, the weight based in part 
upon information received from the proxies. The control node may receive information from the 
plurality of proxies, maintain a list of all proxies, and assigns a weight to each of the proxies in 
the list, the weight based upon information received from the proxies. The control node may 
receive a request and use the weights to assign a proxy. The request may then be forwarded to 
the selected proxy by the control node. (Applicant's Specification at p. 3, lines 4-13). 

Applicants provide Figure 1 which is a diagram illustrating a preferred embodiment of 
the system for load balancing in accordance with the present invention. As Applicants describe 
and referring to Figure 1, a system includes a user agent 102, a first proxy 104, a redirect server 
106, a network 108, a control node 1 10 (including a user agent profile database 111), a location 
server 112, a second proxy 114, third proxy 116, fourth proxy 118, a network 120, and a user 
agent 122. 

The user agent 102 is coupled to the proxy 104. The proxy 104 is coupled to the network 
108 and the redirect server 106. The network 108 is coupled to the control node 110. The 
control node 110 is coupled to the proxies 114, 116, 118, and the location server 112. The 
proxies 114, 116, and 118 are coupled to the network 120. The network 120 is coupled to the 
user agent 122. 

The functions of the user agents 102 and 122 may be implemented by computer 
instructions stored in memory and executed by a processor. A user agent (caller) may transmit 
messages to another agent (callee). The messages may be of any type or format. 

The functions of the proxies 104, 114, 116, and 118 may be implemented using computer 
instructions stored in a memory and executed by a processor. The proxies 104, 114, 116, and 
118 may be stateless or stateful. Also, the proxies 104, 1 14, 1 16, and 118 may stay in the path of 



a call for the duration of a session or may be out of the path. In addition, the proxies may 
implement SIP or any other type of protocol. 

Any of the proxies 104, 114, 116, or 118 may route messages to other proxies or other 
devices. A downstream proxy (e.g., proxies 1 14, 1 16, or 118) may receive messages from other 
proxies (e.g., upstream proxies) or other devices (e.g., the SIPCN). 

The functions of the redirect server 106 may be implemented using computer instructions 
stored in a memory and executed by a processor. The redirect server 106 includes information 
needed to route calls from the caller to the callee across the network 108. 

The networks 108 and 120 may be any type of network used to transmit any type of 
information. In one example, the networks 108 and 120 may be IP networks, which transmit 
packets of information. Other types of networks are possible. 

The functions of the control node 1 10 may be implemented using computer instructions 
stored in a memory and executed by a processor. A list of all downstream proxies is kept on the 
control node. Each of the proxies may be weighted using the information available to the control 
node 110. Once the weighting is performed, messages may be assigned to proxies based upon 
the weighted values. 

Weighting may be done by any number of methods. For example, weighting may be 
done by tracking the traffic load of the proxies; by determining the load on the proxies by 
tracking the delay in the responses of the proxies; or by monitoring the load on the proxies by 
querying specific processes of the proxies. Other types of weighting algorithms may also be 
used. (Applicant's Specification at p. 5, line 3 - p. 6, line 19). 

In order to provide further flexibility in the network, pre-weighting may also be used. 
Pre -weighting allows the SIPCN to ensure that the SPs with lower processor capability are not 
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overloaded. In other words, loads are distributed equitably rather than equally. The pre-weight 
may be manually configured by a network administrator, or may be determined dynamically via 
processes running on the hosts. In one example, process status utilities such as ps, pstat, pmon, 
pulist and pslist may be used. Pre-weighting may be implemented as a field in the SIPCN table. 
The field may indicate the handicap of each SP and contribute to the weighted value of the host. 
This would provide the benefit of allowing a variety of unequal processor hosts to be used within 
the same cluster, as SPs. (Applicant's Specification at p. 12, lines 3 - 12). 

As Applicants also explain, the Voice over Internet Protocol (VoIP) is a technique where 
voice information is packetized and transmitted over a network. VoIP uses signaling to 
establish, modify, and terminate multimedia events. For example, the Session Initiation Protocol 
(SIP) and H.323 represent two methods whereby signaling may be provided. SIP is an 
application-layer call control protocol for VoIP and other media applications. (Applicants' 
Specification at p.2 lines 6 - 13). 

The presently pending independent claims are generally directed to such methods and 
systems for load balancing using Voice over Internet Protocol (VoIP) information received from 
proxies. Such proxies implement the SIP protocol. For example, independent claim 1 expressly 
recites a method of load balancing comprising the step of "receiving at a control node, Voice 
over Internet Protocol (VoIP) information from a plurality of downstream proxies the VoIP 
information including a delay time between the control node and the downstream proxies" and 
that "the proxies implement the SIP protocol." Independent claim 1 has also now been clarified 
and further amended to expressly recite the step of "assigning a weight to each of the 
downstream proxies in the list, the weight based in part upon the VoIP information including the 
delay time received from the downstream proxies and also in part on a pre-weighting of at least 
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one of the downstream proxies in the list ." (emphasis added). The remaining independent 

claims contain similar limitations. 

B. The Cited References Do Not Teach or 

Suggest Applicants' Presently Claimed Invention 

Jordan 652 fails to teach, either expressly or inherently, such a "method of load balancing 
in an upstream proxy" by assigning a weight to each proxy based " in part on a pre-weighting of 
at least one of the downstream proxies in the list ." For example, Jordan '652 appears to teach a 
load monitor for each cache server 150. According to Jordan '652, Figs. 2a-2b provide examples 
of data formats of two tables maintained by the load monitor. As depicted, the tables include a 
load table 102, and a caching table. (Jordan '652, Col. 6 lines 6-10). 

The present Office Action states that Jordan 652 discloses the step of "assigning a weight 
to each of the downstream proxies in the list, the weight based upon information received from 
the downstream proxies" relying in part on Jordan 652 Col. 6, lines 6-25. Applicants 
respectively disagree. 

Jordan 652 does not teach or suggest the limitation expressly recited in claim 1 : assigning 
a weight based in part on VoIP information including a delay time. However, in an effort to 
expedite the allowance of the presently pending claims, Applicants have further modified the 
presently pending claims to further distinguish Jordan 652. As mentioned above, Applicants 
have revised the presently pending claims to further recite the step of assigning a weight based in 
part "upon the VoIP information including the delay time received from the downstream proxies 
and also in part on a pre-weighting of at least one of the downstream proxies in the list ." 

Jordan 652 at Col. 6, lines 6-25 fails to teach such a step. Jordan 652 teaches a load 
table that includes the load condition of each cache server 150 so that overloaded and under 
loaded servers can be identified. Jordan 652 also explains that "conventional" techniques may 
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be used to identify an overloaded cache server and describes such conventional techniques: i.e., 
"the load monitor can compute the mean load of all proxy cache servers in past intervals. 
Overloaded cache servers can be those with loads exceeding a threshold above the mean load." 
Jordan 652 Col. 6, Lines 17-20. Consequently, Jordan '652 does not teach or suggest using VoIP 
information for load balancing by assigning a weight " in part on a pre -weighting of at least one 
of the downstream proxies in the list ." As Applicants explain, in order to provide further 
flexibility in Applicants' network, pre -weighting may also be used. Pre-weighting allows the 
Control Node to ensure that the Proxies with lower processor capability are not overloaded. In 
other words, loads are distributed equitably rather than equally. The pre-weight may be 
manually configured by a network administrator, or may be determined dynamically via 
processes running on the hosts. Jordan 652 does not teach or suggest such a "pre-weighting 
step." The other "art" cited in the presently pending Office Action also does not teach or suggest 
such a pre-weighting step. 

For example, Zisapel 702 appears to teach "load balancing requests among redundant 
network servers in different geographical locations." (Zisapel 702, Col. 1, lines 11-14). Zisapel 
'702 does not teach the use of VoIP information, let alone using VoIP information or messages 
from a plurality of downstream proxies while "distributing a traffic load to one of the plurality of 
downstream proxies based in part on the weight of each of the downstream proxies" and then 
"monitoring the load on the proxies by querying specific processes of the proxies." 

The other cited references fare no better. For example, the present Office Action states 
that "[i]n analogous art, AAPA discloses that proxy servers can implement the SIP protocol (i.e. 
"arrays of SIP proxy servers") (p. 2, lines 20-21) and pass VOIP information (i.e. call 
information) (p 2, lines 7-11, 16-19). Office Action page 4. Applicants respectively traverse. 
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At page 2, lines 7-11 and 16-19, Applicants mention that Voice over Internet Protocol 
(VoIP) is a technique where voice information is packetized and transmitted over a network. 
Applicants do not discuss or describe that VoIP can be used with proxy servers for load 
balancing of a plurality of proxies by assigning a weight to each of the downstream proxies. 

And at page 2, lines 20-21 Applicants mention that in carrier class networks, arrays of 
SIP proxy servers may be used for increased call capacity and redundancy. Applicants do not 
discuss or describe that these SIP proxy servers are used for load balancing of a plurality of 
proxies by assigning a weight to each of the downstream proxies and do not discuss how such an 
array of SIP proxy servers could be used for load balancing, let alone load balancing based in 
part on VoIP data. 

And Primak 585 fares no better than any other cited reference. Primak 585 is generally 
directed to a system and method of directing connections between a client and a server in a 
distributed client server environment. Primak 585 If [0002]. The present Office Action relies on 
para [0025] as teaching capacity information (i.e., load) in order to monitor the load on the 
particular server. However, Primak 585 is not directed to Voice over IP, does not teach the use 
of VoIP information including a delay time between a control node and a downstream proxy and 
does not teach the use of assigning a weight base in part on VoIP including a delay time. Primak 
585 is instead primarily focused on using Domain Name System (DNS) servers to direct a 
client's request to a particular server. 

II. SUMMARY 

The presently pending independent claims 1, 6, 8, 10, 11, 13, 18, and 19 are allowable for 
at least all of the reasons stated above. The remaining pending claims are all dependent on these 
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allowable independent claims and are therefore allowable for at least the reasons stated above. 

Applicants respectfully submit that, in view of the remarks above, the present application 
is in condition for allowance and solicit action to that end. 

If there are any matters that may be resolved or clarified through a telephone interview, 
the Examiner is respectfully requested to contact Applicants' undersigned representative at (312) 



913-0001. 



Respectfully submitted, 

McDonnell Boehnen Hulbert & Berghoff LLP 



Date: February 15,2008 



By: /Thomas E. Wettermann/ 
Thomas E. Wettermann 
Reg. No. 41,523 
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